home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48hor1 / new2q.txt < prev    next >
Text File  |  1995-03-31  |  2KB  |  47 lines
  1. (Comp.sys.handhelds) 
  2. Item: 2604 by billw at hpcvra.cv.hp.com. 
  3. Author: [William C Wickes] 
  4.   Subj: ->Q or Not ->Q 
  5.   Date: Tue Apr 02 1991 
  6.  
  7. From the HP 48 Design Team: 
  8.  
  9.  
  10.                ->Q OR NOT ->Q, THAT IS THE QUESTION 
  11.  
  12. Thanks to Joseph Horn, the HP28/48 community now has additional fast 
  13. rationalization functionality for their machines  [Note: see DEC2FRAC on this 
  14. disk.  -jkh-]  We congratulate him for this elegant solution!  There are a 
  15. number of interesting points regarding DEC2FRACs relation to ->Q which deserve 
  16. some mention.  Perhaps these will stimulate discussion and further 
  17. contributions. 
  18.  
  19. DEC2FRAC is an addition and not a replacement for ->Q because its aim is rather 
  20. different.  DEC2FRAC's aim is to produce the fraction with the _smallest error_ 
  21. and a given denominator size.  ->Q's aim is to produce the fraction with the 
  22. _smallest denominator_ and a given error size.  This is best illustrated with 
  23. the golden mean, '(1+\sqr(5))/2'.  Given this and 1E11, DEC2FRAC returns 
  24. '139583862445/86267571272' while ->Q returns (in STD mode) '514229/317811'. 
  25. When evaluated, these return _exactly_ the same floating point number.  The 
  26. idea of ->Q is to "round to simpler" rather than "round to closer." This is 
  27. useful where you have what you believe to be a "simple" fraction contaminated 
  28. with roundoff or other noise. 
  29.  
  30. The HP48 manuals did little to clarify this issue, especially since we wanted 
  31. to make no specific claim with only a conjecture of correctness.  In this 
  32. regard, posting a proof that the algorithm fills in all possible fractions 
  33. would be a great boon to the community. 
  34.  
  35. While for many "interesting" numbers the continued fraction sequence as 
  36. generated by DUP IP SWAP FP INV ...  is exact, even though the floating point 
  37. representation is not, in other cases, you get "noise" unexpectedly early. 
  38. Does this have any significance regarding the "safety" of generating the 
  39. numerator of the fraction from the denominator by division? 
  40.  
  41. While ->Q keeps around the entire continued fraction sequence entailing some 
  42. speed penalty, there may be other statistics about the sequence (such as 
  43. periodicity) which can be of interest in "deciphering" a floating point number. 
  44. Suggestions along these lines are most welcome. 
  45.  
  46. Thanks again to J. Horn for a stimulating and useful post. 
  47.